home *** CD-ROM | disk | FTP | other *** search
- From: Claus Brod <clausb@hpbeo79.bbn.hp.com>
- Subject: Re: GEMDOS re-entrancy
- Date: Wed, 25 May 94 9:21:41 MESZ
- In-Reply-To: <m0q665O-000ERxC@lloyd.com>; from "Howard Chu" at May 24, 94 4:40 pm
- Mailer: Elm [revision: 70.85]
-
- > 1) GEMDOS must be re-entrant. It isn't.
- >
- > 2) Process B must not make a GEMDOS call. This could lead to some weird
- > multitasking. I guess it would work, but halting the AES when a program
- > tries to load fonts could get kinda hairy. Processes that can't call
- > GEMDOS cannot accept input or display output. This will work, but it's
- > hairy.
- >
- > 3) Make process A sleep OUTSIDE GEMDOS. There must be some way to clean up
- > GEMDOS while process A sleeps, perhaps exiting GEMDOS and putting the
- > process on some sort of wait queue. Then have the process re-enter
- > GEMDOS when the IO is complete. There has GOT to be some way to clean
- > things up.
- >
- > Option 3 sounds interesting, but if you look at it, you will still need to
- > rewrite portions of GEMDOS to support it, so you might as well do the whole
- > thing right with option 1, eh?
-
- Option 2 isn't that hairy as it may seem. It just requires reentrance
- semaphores for AES, VDI and GEMDOS. The effect would be that you couldn't
- call AES while another process is inside AES, but that's exactly
- the same situation as with the current MiNT version. This would
- allows not as much parallelism as we might want, but at least a little
- bit. Option 2 also doesn't involve lots of kernel hacking which I would
- like to refrain from for now.
-
- --clausb@hpbeo79.bbn.hp.com-----------------------------------------------
- Claus Brod, MDD, HP Boeblingen Have you hugged your manager today?
- --#include <std_disclaimer>-----------------------------------------------
-